Systems and methods for communicating logic in e-mail messages

ABSTRACT

Computer program products, apparatus, and methods for processing a human-readable message are provided. The message is received at a first computer in the form of an e-mail. A check is performed to determine whether the message includes (i) a tag originated by a sender of the message and (ii) human-readable instructions interpretable by the first computer to pre-process the message by a pre-process routine. The pre-process routine calls for (i) requesting and receiving, over a network or the Internet from a third computer, data from one or more data fields of a database responsive to the human-readable instructions and (ii) modifying the human-readable message, thereby creating a plurality of processed human-readable messages. When it is determined that the message includes (i) the tag and (ii) the human-readable instructions the message is pre-processed in accordance with the human-readable instructions using the pre-process routine.

RELATED APPLICATION

The application is a continuation of U.S. patent application Ser. No.11/339,906, filed Jan. 25, 2006, entitled “Systems and Methods forCommunicating Logic In E-Mail Messages,” which is hereby incorporated byreference in its entirety.

FIELD OF THE INVENTION

Systems and methods for encoding and interpreting logic encoded ine-mail messages are provided. More particularly, computer systems andmethods for encoding logic in order to send personalized interactivedigital messages are provided.

BACKGROUND OF THE INVENTION

Electronic mail (e-mail) is an essential network service. Most e-mailsystems that send mail over the Internet use simple mail transferprotocol (SMTP) to send messages from one server to another. Themessages can then be retrieved with an e-mail client using services suchas post office protocol (POP) or Internet message access protocol(IMAP).

Other protocols for sending e-mail include POP3, X.400 InternationalTelecommunication Union standard (X.400), and the Novell messagehandling service (MHS), and extended simple mail transfer protocol(ESMTP). Specifically, X.400 defines a transfer protocol for sendingelectronic mail between mail servers and is used in Europe as analternative to SMTP. MHS, which was developed by Novell, is used forelectronic mail on Netware networks.

SMTP transports electronic mail among different hosts within thetransmission control protocol/Internet protocol (TCP/IP) suite. UnderSMTP, a client SMTP process opens a TCP connection to a server SMTPprocess on a remote host and attempts to send mail across theconnection. The server SMTP listens for a TCP connection on a specificport (25), and the client SMTP process initiates a connection on thatport. When the TCP connection is successful, the two processes execute asimple request-response dialogue, defined by the SMTP protocol (see RFC821 STD 10, Simple mail transfer protocol, August 1982, for details), inwhich the client process transmits the mail addresses of the originatorand the recipient(s) for a message. When the server process acceptsthese mail addresses, the client process transmits the e-mail instantmessage. The e-mail message contains a message header and message text(“body”) formatted in accordance with RFC 822 (RFC822 STD 11, Standardfor the format of ARPA—Internet Text Messages, August 1982). Mail thatarrives via SMTP is forwarded to a remote server or it is delivered tomailboxes on the local server. On UNIX-based systems, Sendmail is themost widely used SMTP server for e-mail. Sendmail includes a POP3 serverand also comes in a version for Windows NT. Microsoft Outlook is themost popular mail-agent program on Window-based systems.

The SMTP model (RFC 821) supports both end-to-end (no intermediatemessage transfer agents “MTAs”) and store-and-forward mail deliverymethods. The end-to-end method is used between organizations, and thestore-and-forward method is chosen for operating within organizationsthat have TCP/IP and SMTP-based networks. A SMTP client will contact thedestination host's SMTP server directly to deliver the mail. It willkeep the mail item from being transmitted until it has been successfullycopied to the recipient's SMTP. This is different from thestore-and-forward principle that is common in many other electronicmailing systems, where the mail item may pass through a number ofintermediate hosts in the same network on its way to the destination andwhere successful transmission from the sender only indicates that themail item has reached the first intermediate hop. The RFC 821 standarddefines a client-server protocol. The client SMTP is the one whichinitiates the session (that is, the sending SMTP) and the server is theone that responds (the receiving SMTP) to the session request. Becausethe client SMTP frequently acts as a server for a user-mailing program,however, it is often simpler to refer to the client as the sender-SMTPand to the server as the receiver-SMTP. An SMTP-based process cantransfer electronic mail to another process on the same network or toanother network via a relay or gateway process accessible to bothnetworks. An e-mail message may pass through a number of intermediaterelay or gateway hosts on its path from a sender to a recipient.

A simple model of the components of the SMTP system is shown in FIG. 1.Users deal with a user agent (UA). Popular user agents for UNIX includeBerkeley Mail, Elm, MH, Pine, and Mutt. The user agents for Windowsinclude Microsoft Outlook/Outlook Express and Netscape/MozillaCommunicator. The exchange of e-mail using TCP is performed by an MTA.The most common MTA for UNIX systems is Sendmail, and a conventional MTAfor Windows is Microsoft Exchange 2000/2003. Users normally do not dealwith the MTA. It is the responsibility of the system administrator toset up the local MTA. Users often have a choice, however, for their useragent. The local MTA maintains a mail queue so that it can schedulerepeat delivery attempts in case a remote server is unable. Also thelocal MTA delivers mail to mailboxes, and the information can bedownloaded by the UA (see FIG. 1). The RFC 821 standard specifies theSMTP protocol, which is a mechanism of communication between two MTAsacross a single TCP connection. The RFC 822 standard specifies theformat of the electronic mail message that is transmitted using the SMTPprotocol (RFC 821) between the two MTAs. As a result of a user mailrequest, the sender-SMTP establishes a two-way connection with areceiver-SMTP. The receiver-SMTP can be either the ultimate destinationor an intermediate one (known as a mail gateway). The sender-SMTP willgenerate commands, which are replied to by the receiver-SMTP (see FIG.1).

Both the SMTP client and server have two basic components: UA and localMTA. There are few cases of sending electronic-mail messages acrossnetworks. In the first case of communication between the sender and thereceiver across the network (see FIG. 1), the sender's UA prepares themessage, creates the envelope, and puts message in the envelope. The MTAtransfers the mail across the network to the TCP-port 25 of thereceiver's MTA. In the second case of communication between the sendinghost (client) and the receiving host (server), relaying could beinvolved (see FIG. 2). In addition to one MTA at the sender site and oneat the receiving site, other MTAs, acting as client or server, can relaythe electronic mail across the network. This third scenario ofcommunication between the sender and the receiver can be accomplishedthrough the use of an e-mail gateway, which is a relay MTA that canreceive electronic mail prepared by a protocol other than SMTP andtransform it to the SMTP format before sending it. The e-mail gatewaycan also receive electronic mail in the SMTP format, change it toanother format, and then send it to the MTA of the client that does notuse the TCP/IP protocol suite. In various implementations, there is thecapability to exchange mail between the TCP/IP SMTP mailing system andthe locally used mailing systems. These applications are called mailgateways or mail bridges. Sending mail through a mail gateway may alterthe end-to-end delivery specification, because SMTP will only guaranteedelivery to the mail-gateway host, not to the real destination host,which is located beyond the TCP/IP network. When a mail gateway is used,the SMTP end-to-end transmission is host-to-gateway, gateway-to-host orgateway-to-gateway; the behavior beyond the gateway is not defined bySMTP.

E-mail across SMTP, or the other protocols references above, is usedextensively today to communicate relevant personalized information. Forexample, a company needs to frequently communicate to each of itsnumerous consumers with relevant personalized e-mail. In such asituation, companies often maintain information specific to each of itscustomers or clients in a data repository, such as customer databases,data files, customer relationship management (CRM) systems, and thelike. One approach for communicating with all of these customers is tosend personalized individual, batch, or bulk e-mail through an e-maildistributor or high-throughput mail transfer agent (MTA) system.

A mail transfer agent or MTA (also called a mail server, or a mailexchange server in the context of the Domain Name System) is a computerprogram or software agent that transfers electronic mail messages fromone computer to another. Webster's New World Computer Dictionary, tenthedition, Wiley Publishing Inc., Indianapolis, Ind., defines an MTA as ane-mail program that sends e-mail messages to another message transferagent. An MTA can handle large amounts of mail, can interact withdatabases in many formats, and has extensive knowledge of the many SMTPvariants in use. Examples of high-throughput MTA systems are disclosedin U.S. patent application Ser. No. 10/857,601, entitled “Email DeliverySystem Using Metadata,” filed May 27, 2004 as well as U.S. patentapplication Ser. No. 10/777,336, entitled “Email Using Queues inNon-persistent memory,” filed Feb. 11, 2004, each of which is herebyincorporated by reference in its entirety. One example of an MTA systemis the StrongMail MTA (Redwood Shores, Calif.). Conventional MTAprograms include, but are not limited to, sendmail, qmail, Exim, andPostfix.

High-throughput MTA systems such as those described above are morepowerful than conventional MTA programs. Both high-throughput andconventional MTA products can send out messages to a plurality ofrecipients. However, while functional, existing MTA systems areunsatisfactory. To illustrate why, consider the case in which company Awishes to communicate with existing or past customers. The companymaintains a record of each of these customers in a company database.Such records may contain personalized information about each of thecustomers. Company A wishes to use this information in order tocustomize each of the e-mails. To accomplish this, a method foraccessing the customer information in the database needs to be arranged.Separately, the design of the e-mail that will be sent to each customerin the distribution list needs to be created. Therefore, at a minimum,what is needed is coordination between an information technology (IT)specialist and a business development professional in order to configuredata from one or more sources to create messages to be delivered usingthe MTA distribution.

An IT specialist is consulted in order to provide a secure method forquerying the database containing customer information. For instance, theIT specialist might set up an account with limited database privilegesas well as construct scripts with customized database queries in orderto obtain the information for each customer. At a minimum, suchinformation will include an e-mail address for each customer. In morepowerful examples, the names of the customers are identified, as well asother information such as the types of products the customer has boughtin the past, geographic information, information about the customerpayment history, how often the customer buys products, how much productthe customer buys, and so forth. Thus, it is clear that an IT specialistis needed in conventional MTA based distribution efforts each time abusiness development professional designs a new e-mail for distributionusing an MTA. The role of the business development professional is tooptimize the persuasiveness and effectiveness of the customized MTAdistribution. The work of the business development professional involveschoosing fonts, color schemes and art that will be used in thecustomized e-mail sent to a plurality of recipients. The work of thebusiness development professional further involves making decisionsabout which customers will receive a customized e-mail. The businessdevelopment professional can, for example, select customers as afunction of geographic region, amount of product bought from the companyduring a predetermined time period, etc. Thus, close coordinationbetween the business development professional and the IT specialist isneeded for each business development project that involves thedistribution of customized electronic messages using an MTA.

The business development example provided above is just one example ofthe many applications that can be implemented using e-mail. Otherapplications include providing secure custom statements (e.g., bankingstatements), person-to-person customized e-mail, traceable e-mails,e-mails from customer service to existing customers, e-mails from anemployer to an employee, etc. However, conventional user agents do notprovide satisfactory methods for supporting such features. As theexample above shows, complex steps are necessary in order to supportsuch applications. Accordingly, given the above background, what areneeded in the art are improved systems and methods for generating andinterpreting customized e-mail messages for distribution.

Discussion or citation of a reference herein will not be construed as anadmission that such reference is prior art to the present invention.

SUMMARY OF THE INVENTION

The present invention addresses many of the shortcomings and drawbacksfound in the prior art. In the present invention logic is encoded intoe-mail messages sent from a client computer using the SMTP, POP3, X.400,ESMTP, or MHS protocols or logical variants thereof (e.g., e-mailmessages sent using programs similar to or derived from SMTP, POP3,X.400, ESMTP or MHS). The logic encoded by such e-mail is processed byan MTA, in accordance with the present invention. Examples of the logicthat can be encoded in the e-mail (herein termed the “electronicrequest”) includes but is not limited to the use of variables, branchconditions (e.g., if then else), loop conditions (e.g., for loop),customized database queries and the like. By processing the logicencoded in the e-message at the MTA housed on a server, rather than onthe client, resources readily accessible to the server, but not theclient, can be queried in a highly customizable manner in order toproduce highly customizable e-mail. Such procedures have application ina broad array of e-mail applications, including but not limited to,customized business develop e-mail, secure custom statements (e.g.,banking statements), person-to-person customized e-mail, traceablee-mails, e-mails from customer service to existing customers, customerrelationship management, e-mails from an employer to an employee, andautomated e-mail reports from devices such as appliances.

One aspect of the invention provides systems and methods for encodinginstructions to access customer data repositories in order to generateencoded messages, such as e-mail messages, that can be distributed byservices such as an MTA. With these systems and methods, an ITprofessional, for example, sets up an outbound request, such ascustomized database queries, or web services requests or flat file dataaccess on a one time basis for a business development professional.After this, the business development professional or other worker cancreate and modify customized electronic requests for mass distributionusing services, such as an MTA, without any further need forconsultation with an IT professional using any user agent that isdesigned to send digital messages (e.g. Outlook, Siebel, Hotmail, etc.).

The systems and methods of the present invention make use of existingmail transfer protocols. For example, an electronic request can beforwarded to an MTA using the SMTP protocol (or any of the other mailtransfer protocols or their derivatives described above) in order toprovide the MTA with all the information necessary to send out highlycustomized e-mail to one or a plurality of recipients. In one example,such information includes any necessary logic for accessing select datarepositories in order to retrieve customer data for personalizing batche-mail messages. In particular, using the systems and methods of thepresent invention, a user sends a specialized electronic request to aservice such as an MTA. This electronic request is in the form of ane-mail message that can be sent to an MTA by a mail transfer protocolsuch as SMTP. In some embodiments this electronic request is an EXMLmessage. EXML is a version of XML (eXtensible Markup Language), which isa simplified markup language that is designed for web documents. LikeXML, EXML enables users to create their own customized tags to providefunctionality not available within HTML. For example, XML supports linksthat point to multiple documents, as opposed to HTML links, whichreference a single destination. XML-like languages facilitate thesharing of data across different systems, particularly systems connectedvia the Internet. Languages based on XML (for example, RDF/XML, RSS,MathML, XHTML, SVG, and cXML) are defined in a formal way, allowingprograms to modify and validate documents in these languages withoutprior knowledge of their form. Although EXML is used as the predominantexample to illustrate the methods and systems of the present invention,the scope of the invention encompasses any language that is capable ofembedding logic into an e-mail that is then communicated to an MTA usinga protocol such as SMTP.

In some embodiments in accordance with the present invention, theelectronic request is included in the body of an E-mail message. In suchembodiments, the electronic request contains logic for how to constructencoded messages (e.g., encoded e-mail). Such encoded messages can thenbe distributed to one or more recipients using an MTA. The electronicrequest can be coded, for example, in an extensible markup languagehaving specific list and token features designed for retrieving data andformatting the e-mails. In some embodiments, the template and therecipient list is included in the common body of the electronic request.Alternatively, in some embodiments, one or more EXML messages may alsobe included as attachments to an e-mail message, which will then beinterpreted by the MTA.

In some embodiments, information necessary to construct the customizedencoded messages that are distributed to recipients are found in one ormore databases and/or one or more flat text files. In such instances,the electronic request includes instructions for how to access suchdatabases and/or flat files and how to process the information containedin these data structures in order to create customized digital messagesfor distribution.

Another aspect of the present invention provides a novel MTA that isconfigured to receive and parse the electronic requests described above.As such, the novel MTA has the functionality of a conventional MTA. Thisconventional functionality includes the ability to process e-mails thatare compliant with the SMTP, POP3, X.400, ESMTP or MHS protocol or avariant thereof (e.g., a program similar to or derived from SMTP, POP3,X.400, ESMTP or MHS). The ability to process such e-mails is a serviceoffered by conventional MTAs. In addition to this conventional ability,the novel MTA of the present invention can recognize an electronicrequest in accordance with the present invention that is sent to theMTA. When the novel MTA identifies such an electronic request, the MTAserves as a personalization module that parses the electronic request inorder to generate and send personalized e-mails based on instructionscontained within the electronic request.

One aspect of the invention provides a method of distributing one ormore encoded messages (e.g., customized e-mail) to a corresponding oneor more recipients using the SMTP, POP3, X.400, ESMTP or MHS protocol ora variant thereof (e.g., a program similar to or derived from SMTP,POP3, X.400, ESMTP or MHS). In the method, an electronic request isreceived by an MTA. The electronic request includes instructions foraccessing one or more (e.g., a plurality) e-mail destinationscorresponding to the one or more recipients. The electronic requestfurther includes instructions for accessing customization data relatingto the recipients. The electronic request also includes instructionsthat define a message body (e.g., a message template) for use in the oneor more encoded messages. In the method, customization data relating torecipients is obtained using the instructions for accessingcustomization data defined in the electronic request. For eachrespective recipient, a message body corresponding to the recipient isformatted using customization data relating to the respective recipientobtained by the method. In this way, one or more encoded messages areconstructed. Finally, the one or more encoded messages is distributed toa corresponding one or more recipients.

Another aspect of the present invention provides a computer programproduct for use in conjunction with a computer system. The computerprogram product comprises a computer readable storage medium and acomputer program mechanism embedded therein.

The computer program mechanism comprises instructions for receiving anelectronic request using the SMTP, POP3, X.400, ESMTP or MHS protocol ora logical variants thereof (e.g., a program similar to or derived fromSMTP, POP3, X.400, ESMTP or MHS). The electronic request includesinstructions for accessing one or more destinations corresponding to oneor more recipients. The electronic request further includes instructionsfor accessing customization data relating to the recipients. Theelectronic request also includes instructions that define a message bodyfor use in one or more encoded messages that are sent to the recipients.The computer program mechanism further comprises instructions forobtaining customization data relating to the recipients using theinstructions for accessing customization data defined in the electronicrequest. The computer program mechanism further comprises instructionsfor formatting, for each respective recipient, a message bodycorresponding to the respective recipient using customization datarelating to the respective recipient obtained by the instructions forobtaining. This allows for the construction of one or more encodedmessages. The computer program mechanism also comprises instructions fordistributing the one or more encoded messages to the recipients.

Still another aspect of the invention comprises a computer system fordistributing one or more encoded messages to a corresponding one or morerecipients. The computer system comprises a central processing unit anda memory that is coupled to the central processing unit. The memorystores a message personalization module and a transfer agent module. Themessage personalization module comprises instructions for receiving anelectronic request using the SMTP, POP3, X.400, ESMTP or MHS protocol ora logical variant thereof (e.g., a program similar to or derived fromSMTP, POP3, X.400, ESMTP or MHS). This electronic request includesinstructions for accessing a plurality of destinations (e.g., e-maildestinations, FAX numbers, etc.) corresponding to the recipients. Theelectronic request further includes instructions for accessingcustomization data relating to recipients. The electronic request alsoincludes instructions that define a message body for use in one or moreencoded messages to correspondingly be sent to the one or morerecipients. The message personalization module also comprisesinstructions for obtaining customization data relating to the recipientsusing the instructions for accessing customization data defined in theelectronic request. The message personalization module also comprisesinstructions for formatting, for each respective recipient, a messagebody corresponding to the respective recipient using customization datarelating to the respective recipient. The mail transfer agent modulecomprises instructions for distributing one or more encoded messages tothe one or more recipients. In some embodiments, the messagepersonalization module is a component of the mail transfer agent module.In some embodiments, the mail transfer agent module is a component ofthe message personalization module. In some embodiments, the mailtransfer agent module and the message personalization module areseparate computer programs. In some embodiments, the mail transfer agentmodule and the message personalization module are within the samecomputer program.

Still another aspect of the invention is a computer program product foruse in conjunction with a computer system. The computer program productcomprises a computer readable storage medium and a computer programmechanism embedded therein. The computer program mechanism comprisesinstructions for sending an electronic request using the SMTP, POP3,X.400, ESMTP or MHS protocol or a logical variant thereof (e.g., aprogram similar to or derived from SMTP, POP3, X.400, ESMTP or MHS). Theelectronic request includes instructions for accessing a one or moredestinations corresponding to one or more recipients. The electronicrequest further includes instructions for accessing customization datarelating to the one or more recipients. The electronic request furtherincludes instructions that define a message body for use in one or moreencoded messages sent to the one or more recipients.

Yet another aspect of the present invention provides a computer systemcomprising a central processing unit and a memory that is coupled to thecentral processing unit. The memory comprises instructions for sendingan electronic request using the SMTP, POP3, X.400, ESMTP or MHS protocolor a logical variant thereof (e.g., a program similar to or derived fromSMTP, POP3, X.400, ESMTP or MHS). The electronic request includesinstructions for accessing one or more destinations corresponding to oneor more recipients. The electronic request further includes instructionsfor accessing customization data relating to the recipients. Theelectronic request also includes instructions that define a message bodyfor use in sending one or more encoded messages to the one or morerecipients.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is the basic simple mail transfer protocol (SMTP) model inaccordance with the prior art.

FIG. 2 is the simple mail transfer protocol (SMTP) model with relay mailtransfer agents in accordance with the prior art.

FIG. 3 is a schematic diagram of a client computer system for sending anelectronic request message for generating encoded messages in accordancewith an embodiment of the present invention.

FIG. 4 is a schematic diagram of a system according to the presentinvention for generating and sending encoded messages from a user inaccordance with an embodiment of the present invention.

FIG. 5 is a flowchart depicting a method of sending encoded messages toone or more intended recipients using encoded instructions from a userin accordance with an embodiment of the present invention.

Like reference numerals refer to corresponding parts throughout theseveral views of the drawings.

DETAILED DESCRIPTION

The present invention encompasses systems and methods for providing anelectronic request (encoded e-mail) to a processing module, such as anof the present invention MTA, using the SMTP, POP3, X.400, ESMTP or MHSprotocol or a logical variant thereof (e.g., a program similar to orderived from SMTP, POP3, X.400, ESMTP or MHS). Upon receipt of theelectronic request, the processing module generates a customized e-mailusing data from a data repository or any other data source. For ageneral reference regarding e-mail protocols, see Hughes, 1998, InternetE-mail: Protocols, Standards, and Implementation, Artech HousePublishers, which is hereby incorporated herein by reference in itsentirety.

FIG. 3 details an exemplary system that supports the functionalitydescribed above. The system is preferably a computer system 10 having:

-   -   a central processing unit 22;    -   a main non-volatile storage unit 14, for example, a hard disk        drive, for storing software and data, the storage unit 14        controlled by controller 12;    -   a system memory 36, preferably high speed random-access memory        (RAM), for storing system control programs, data, and        application programs, comprising programs and data loaded from        non-volatile storage unit 14; system memory 36 may also include        read-only memory (ROM);    -   a user interface 32, comprising one or more input devices (e.g.,        keyboard 28) and a display 26 or other output device;    -   a network interface card 20 or other communication circuitry for        connecting to any wired or wireless communication network 34        (e.g., the Internet or any other wide area network);    -   an internal bus 30 for interconnecting the aforementioned        elements of the system; and    -   a power source 24 to power the aforementioned elements.

Operation of computer 10 is controlled primarily by operating system 40,which is executed by central processing unit 22. Operating system 40 canbe stored in system memory 36. In addition to operating system 40, in atypical implementation, system memory 36 can include one or more of thefollowing:

-   -   file system 42 for controlling access to the various files and        data structures used by the present invention;    -   a customer data repository 44 including a plurality of records        46, each record 46 corresponding to a particular customer, for        example, data related to customer name 48, account information        50, financial records 52, and other customer data 54;    -   other data repositories, databases or data structures 56,        including records 58 which may be resident in memory 36 or        addressable by system 10 through a network connection, storage        media interface, or the like;    -   an e-mail client 60 for sending an electronic request (e.g., an        EXML message) to a personalization module on a remote computer        (server) using a data network and/or Internet;    -   optional message tools 62 and/or templates to aid in generating        an electronic request with instructions to the personalization        module for retrieving customization data (e.g., customer data)        and formatting encoded messages (e.g., e-mails) for distribution        by a software program such as an MTA; and    -   an optional customer relationship management module 70.

As illustrated in FIG. 3, computer 10 comprises software program modulesand data structures. The data structures stored in computer 10 include,for example, customer data repository 44 and one or more other databases56 (e.g., an enterprise resource planning database, a human resourcedatabase, a supply chain database, etc.). In some embodiments, customerdata repository 44 is replaced with other forms of customization datasuch a site-specific maps, weather, specific forms on news, market data,conference room availability, etc. In some embodiments, suchcustomization data is in addition to customer data repository 44. Eachof these data structures can comprise any form of data storageincluding, but not limited to, a flat ASCII or binary file, an Excelspreadsheet, a relational database (SQL), or an on-line analyticalprocessing (OLAP) database (MDX and/or variants thereof). In someembodiments, customer data repository 44, optional databases 56, andcustomer relationship management module 70 are not housed on client 10,but rather are housed on a server that includes the MTA the processesthe electronic request generated by client 10 and/or are located oncomputers that are in electronic communication with such a server.

In some embodiments, each of the aforementioned data structures that arestored on or are accessible to system 10 is a single data structure. Inother embodiments, such data structures, in fact, comprise a pluralityof data structures (e.g., databases, files, archives) that may or maynot all be hosted by computer 10. For example, in some embodiments,repository 44 comprises a plurality of structured and/or unstructureddata records that are stored either on computer 10 and/or on computersthat are addressable by computer 10 across network/Internet 34.

In some embodiments, data repository 44 and/or database 56 comprises adatabase that is either stored on computer 10 or is distributed acrossone or more computers that are addressable by computer 10 bynetwork/Internet 34. Thus, in some embodiments, one or more of such datastructures is hosted by one or more remote computers (not shown). Suchremote computers can be located in a remote location or in the same roomor the same building as computer 10. As such, any arrangement of thedata structures and software modules illustrated in FIG. 1 on one ormore computers is within the scope of the present invention so long asthese data structures and software modules are addressable by computer10 across network/Internet 34 or by other electronic means. Moreover,other systems, application modules and databases not shown in FIG. 1 canbe stored in system memory 36. Thus, the present invention fullyencompasses a broad array of computer systems.

In some embodiments, client computer 10 is used to store customer data46, 56 or other forms of customization data and to send an electronicrequest to a personalization module on a remote computer. The electronicrequest comprises instructions for retrieving customer data fromcustomer data repository 44 and/or database 56 and/or CRM 70 and/orother sources of customization data (e.g., maps, weather). Theelectronic request further comprises instructions for formatting encodedmessages such as E-mail messages. The electronic request can compriseinstructions for a single digital message for a single recipient.Alternatively the electronic request can comprise instructions for aplurality of encoded messages each intended for a different recipient.Such encoded messages can be distributed by e-mail, SMS, FAX, IM, voice,or any other digital communication process. However, in preferredembodiments, the encoded messages are e-mail messages. In someembodiments, client 60 is used to send this electronic request. In someembodiments, the electronic request is constructed using text editingfunctionality directly provided by client 60. In other embodiments,optional message tools 62 are provided to assist in the creation of theelectronic request. Such message tools can include, for example, agraphical user interface (GUI) driven XML and/or HTML editor fordesigning the appearance of customized e-mails for distribution. In suchembodiments, message tools reduce the image produced using the GUI to aset of commands for inclusion in the electronic request. Although SMTPis used to introduce and illustrate the concepts of the presentinvention, the scope of the invention is not limited to SMTP. Forexample, extended simple mail transfer protocol (ESMTP) has beendeveloped to meet the increasing demands of attaching various types offiles to e-mails. ESMTP specifies additional extensions to the originalprotocol for sending e-mail that supports graphics, audio and videofiles, and text in various national languages. Other examples of mailprotocols that can be used to send an electronic request to an MTAinclude, but art not limited to, POP3, X.400, or MHS protocols orlogical variants thereof (e.g., e-mail messages sent using programssimilar to or derived from POP3, X.400, or MHS).

In some embodiments the electronic request is compliant with one of theaforementioned e-mail protocols and is encoded in the XML language. XMLis described in, for example, Ray, Learning XML, second edition,O'Reilly Associates; Harold and Means, XML in a Nutshell, third edition,O'Reilly Associates; and Hunter et al., Beginning XML, third edition,Wrox, each of which is hereby incorporated herein by reference in itsentirety.

Now that an overview of a client system in accordance with oneembodiment of the present invention has been described, variousadvantageous methods that can be used in accordance with the presentinvention will now be disclosed in conjunction with FIGS. 2 and 3.

Referring to FIG. 4, in an embodiment in accordance with the presentinvention, user computer 10 is used to generate an electronic request,in the form of an e-mail message, that includes encoded instructions.User computer further sends the electronic request to digitalpersonalization server 202. In the embodiment illustrated in FIG. 1,server 202 includes MTA functionalities in addition to thefunctionalities of the present invention. In other embodiments, server202 includes functionality for distributing other forms of digitalcommunication such as SMS, FAX, IM, or voice mail. The server 202illustrated in FIG. 2 comprises:

-   -   a CPU 222;    -   a main non-volatile storage unit 214 controlled by controller        212;    -   a system memory 236, preferably high speed random-access memory        (RAM), for storing system control programs such as operating        system 240 and file system 242, data and application programs        loaded from non-volatile storage unit 214; system memory 236 may        also include read-only memory (ROM);    -   a user interface 232, comprising one or more input devices        (e.g., keyboard 228) and a display 226 or other output device;    -   a network interface card 220 or other communication circuitry        for connecting to any wired or wireless communication network        and/or Internet 34;    -   an internal bus 230 for interconnecting the aforementioned        elements of the system; and    -   a power source 224 to power the aforementioned elements.

EXML messages of the present invention can be sent, for example, bye-mail from client 10 to digital message personalization module server202 when a user desires to have server 202 generate and send one or moreencoded messages, such as personalized or customized e-mails, to one ormore intended recipients 206, e.g., clients, customers, potentialcustomers, and/or any other desired recipients for whom the user hasaccess to personalized data in a data repository 204. The electronicrequest provides instructions for generating and sending the encodedmessages, and includes information for formatting the encoded messagesas well as instructions for retrieving the personalized data from datarepository 204.

In some embodiments in accordance with the present invention, server 202is external with respect to client 10 (e.g., FIG. 2). In someembodiments in accordance with the present invention, the encodedmessages are sent from server 202. Alternatively, in other embodimentsin accordance with the present invention, server 202 is an integral partof recipient 206. In still other embodiments in accordance with thepresent invention, client 10 is an integral part of server 202.

FIG. 5 provides a general overview of a method 300 for sendingcustomized encoded messages to intended recipients in accordance with anelectronic request from a user. In step 310, a user creates anelectronic request at client 10. This electronic request can includetext, markup language (e.g., HTML, WML, BHTML, RDF/XML, RSS, MathML,XHTML, SVG, cXML or XML), or other scripts or objects. In someembodiments, the electronic request is created directly using e-mailclient 60 (FIG. 3). In some embodiments, the electronic request iscreated using optional Message tools 62 (FIG. 3). From here, the presentinvention provides different possibilities (use cases).

In one possible use case, the user sends the electronic request directlyto personalization server 202 as noted in step 312 of FIG. 5 usingclient 60 (FIG. 3). To illustrate this use case, consider a situation inwhich marketing manager John creates a single electronic request in theform of an e-mail using computer 10 of FIG. 3 that contains a list ofrecipient users, personalization tokens and predefined tokens, and alsocontains a message body that uses these tokens. John sends theelectronic request using standard Outlook/Exchange (an example of client60) to exml@XYZ.com, the address of message personalization module 244.The module 244 interprets the instructions and data in the electronicrequest and sends fully personalized encoded messages, in the form ofe-mail, to all the final recipients.

In another possible use case, the user sends an electronic request toCRM 70 before the electronic request is sent to personalization server202 in accordance with step 312 of FIG. 5. To illustrate this use case,consider the situation in which marketing manager Debbie decides to makeused of CRM system 70 of FIG. 3. The CRM system already does somelimited personalization. Debbie creates a new electronic requesttemplate that contains more extensive personalization than the use casepresented above (e.g., by using XML/XSLT). The electronic request thatDebbie wishes to make can be created in at least two different ways. Inone approach, the electronic request is created by message tools 62(e.g., Outlook/Exchange) and sent to CRM 70 where static CRM tokens inthe electronic request are populated. Then, the electronic request issent from CRM 70 of computer 10 to personalization module 244 ofcomputer 202. In another approach, the electronic request is createddirectly in CRM module 70. Regardless of how the electronic request isoriginated, rather than sending the messages encoded by Debbie'selectronic request directly from CRM 70 to one or more recipients, theencoded message is sent with to a specific address, e.g., exml@XYZ.com,in this example, message personalization module 244.

In yet another possible use case, the user sends the electronic requestdirectly to e-mail personalization server 202 as noted in step 312 ofFIG. 5 using e-mail client 60 (FIG. 1). The electronic request containsmultiple levels of information. To illustrate this use case, consider asituation in which sales manager Mark creates an EXML template usingcomputer 10 of FIG. 1. This is one form of electronic request. The EXMLtemplate contains a list of Mark's customers, personalization tokens andpredefined tokens, and also contains a message body that uses thesetokens. The predefined tokens correspond to functions comprising meetingscheduling, sending out pre-formatted correspondence (e.g., salesfollow-up materials). Mark sends the electronic request using standardOutlook/Exchange (an example of E-mail client 60) to exml@XYZ.com, theaddress of message personalization module 244. The module 244 interpretsthe EXML instructions and data and sends fully personalized encodedmessages (e.g., encoded e-mails) to one or more final recipients.

Referring to step 314, regardless of which use case is employed inpreceding steps, server 202 reads the electronic request sent by client10 in order to determine whether the electronic request encodes for theencoded messages of the present invention. Specifically, in oneembodiment, message personalization module 244 reads the message in step314. If a specialized tag (e.g., an <EXML> tag) is not present in themessage (step 314—No), message personalization module 244 cedes controlto mail transfer agent module 246. Mail transfer agent module 246, inturn, processes the message in a conventional fashion by forwarding themessage to the one or more intended recipients. In some embodiments inaccordance with the present invention, the mail transfer agent (MTA)module 246 is a message server having MTA and/or electronic-MTAcapabilities.

Returning to the embodiment illustrated in FIG. 4, when messagepersonalization module 244 determines that a specialized tag (e.g., an<EXML> tag) is present in the message (step 314—Yes), this indicatesthat the message is an electronic request. In such instances, theelectronic request (e.g., EXML message) is parsed (step 316) by messagepersonalization module 244 and one or more customized digital messages(e.g., one or more e-mail messages) are custom generated in accordancewith the instructions contained within the electronic request (step318). The delineation of a separate message personalization module 244and mail transfer agent 246 as two separate modules is for illustrativepurposes only. In some embodiments, message personalization module 244and mail transfer agent module 246 are contained in the same softwareprogram. As such, the description of message personalization module 244and mail transfer agent module as separate modules is merely providedherein to best illustrate the functionality of the MTAs of the presentinvention.

Referring to step 320, if the electronic request does not include a<FINAL_RECIPIENT> tag or some equivalent information for personalizingthe message for a number of recipients (320—No), then mail transferagent module 246 forwards the encoded request to the one or moreintended recipients 324. If, however, a <FINAL_RECIPIENT> tag is presentin the electronic request (320—Yes), then personalized encoded messagesare generated for each specified recipient in 322. In some embodiments,there is only a single recipient. In some embodiments, the recipient isone or more computers (e.g., a blog site). In some embodiments, the<FINAL_RECIPIENT> instruction includes a pointer to database customerdata repository 44 and/or other database 56. Repository 44 and/ordatabase 56 is stored in client computer 10 and/or a computer that isaddressable by client computer 202. In other words, in some embodimentsthe FINAL_RECIPIENT tag is in fact a dynamic token that accesses data atan external address. In step 324, the encoded messages are forwarded tothe intended recipients by mail transfer agent module 246.

One advantage of the encoding methods of the present invention is thatthere is no absolute requirement for a specialized user interface inorder to create an electronic request. For example, one can simply usean application such as Microsoft Outlook, and add lists from aspreadsheet, if desired. In fact, the electronic request can beconstructed in a simple ASCII editor. In some embodiments, if a user hasdata in a customer relationship management database (e.g., Siebel orOracle), enhanced functionality such as tracking, dynamic content, andthe like can be utilized and/or incorporated to generate and sendencoded messages such as personalized e-mail messages.

In some embodiments, the systems and methods of the present inventionprovide a user with the ability to encode instructions in the electronicrequest that instruct message personalization module 244 to access datafrom, or provide data to, data repositories stored in external systems(e.g., customer data repository 44 and/or other database 56 or flat filestored by or addressable by computer 202). Such data repositories caninclude, for example, one or more hierarchical databases, and/or one ormore relational databases, and/or one or more other data structures orflat files. As illustrated in FIG. 4, data can be retrieved orsubmitted, for example, over network connection 34 or from storage mediaprovided to the message personalization module 244. In FIG. 4, messagepersonalization module 244 can communicate with one or more externaldatabases 402, HTTP web services 404, or TCP/IP web services 406 usingnetwork connection 34. Using the systems and methods of the presentinvention, such resources can be accessed in order to provide securecustom statements (e.g., banking statements), person-to-personcustomized e-mail, traceable e-mails, e-mails from customer service toexisting customers, e-mails from an employer to an employee, etc.

In some embodiments, for example for data security reasons, access to anentire customer database may be denied. In such embodiments, one or morefiles containing only the data required to generate the desired messagesis made available to message personalization module 244 and/or mailtransfer agent module 246.

In some embodiments, the electronic request includes limited or fullaccess rights to a users' data repository. For example, an electronicrequest can include a command that defines limited or full login rights,limited or full query rights, access to only certain records, fields orfiles or certain portions of a database or data repository, access for alimited period of time, and the like.

In some embodiments, certain destinations associated with messagepersonalization module 244 and/or mail transfer agent module 246 can bedesigned to be <EXML> enabled. For example, a particular mailbox calledexml@strongmailsystems.com (or exml@mtacompany.com) can be set up sothat, when a user sends an electronic request to such an address, therequest is parsed by message personalization module 244 and encodedmessages are distributed by mail transfer agent module 246 based on theproduct of message personalization module 244 after parsing the EXMLmessage.

In some embodiments, a customer relationship management system has theability to personalize encoded messages (e.g. encoded e-mails) based ondatabase tokens. In such embodiments, user computer 10 can originate anelectronic request template that contains EXML formatting and datapointer information. In one example, for each digital message (e.g.,e-mail) specified by the electronic request, the First_Name andAccount_ID of each customer in a customer list can be represented, forexample, as EXML tokens in the body of the electronic request. Theelectronic request containing these tokens is then sent to server 202,which then uses advanced parsing techniques to: (i) personalize themessage (e.g., process as “Dear ##First_Name##, . . . ”); (ii) add clicktags and open tags; and (iii) apply XML/XSL rules that can furthercustomize the digital message. In such instances, the output can beencoded e-mail messages, or other forms of encoded messages,personalized by the items above. Such encoded messages are then sent toeach recipient specified by the original electronic request.

In another embodiment, client 10 creates a single electronic request(e.g., e-mail) using EXML encoding with the full list of recipients 206and the tokens/instructions for formatting. The receiving system 202receives this electronic request, interprets the EXML, and thengenerates one or more outgoing encoded messages (e.g., e-mail, FAXes,IM, voice, etc.) based upon the list and the personalizationinstructions in the electronic request.

A more detailed example of an electronic request for encoding messagesthat can be distributed by an MTA system in accordance with anembodiment of the present invention is reproduced below as lines 100through 191 of XML code.

100 <EXML> 101 <TYPE=“test”> 102 <!-- Type=“test” will validate themessage only 103 and send back any errors to the sender, it 104 will notsend the production mailing. 105 Note that the errors will be sent backto the sender 106 within another RETURN TO email with the errors and the107   actual line(s) that caused the error(s).--> 108 <!-- Static Tokens--> 109 <STATIC_TOKENS> 110   <!-Static Tokens: Literals --> 111    ZIP_CODE = 94555 112     MAILINGID = 1234 113   <!-Static Tokens:CRM tokens --> 114     CRM_EMAIL =  [% email %] 115     CRM_FIRST_NAME=  [% fname %] 116     CRM_LAST_NAME =  [% lname %] 117    CRM_ACCOUNT_ID =  [% cid %] 118   <!-- Static Tokens: Predefined byeMTA --> 119   <!-- Available Predefined Tokens - already --> 120   <!--defined in eMTA 121   VIRTUAL_SERVER: Virtual routing: virtual servers122     that have different characteristics for different 123    classes of digital messages 124   ##CANSPAM##: CAN SPAM: legalcompliance with the 125     CAN-SPAM law 126   ##HABEAS_HEADERS##:Headers - special headers for 127     reputation e.g. Habeas headers 128  ##TRACK## or ##OPENTAG##: Tracking (opens clicks 129       unsubs):tracking of opens/clicks/unsubs with 130     personalized links 130  XML/XSL rules: personalization rules coded in 131   standard XSL 132  Reporting: reporting based on mailing-id, 133 message-id, etc. --> 134</STATIC_TOKENS> 135 <!-- Static Tokens --> 136 <DYNAMIC_TOKENS> 137  BANK_BRANCHES= 138     <SQL DBHOST=“db-host1”DBUSER=“smail” 139      DBPASSWD=“1234”> 140       SELECT branch_names 141       FROMbranch_table 142       WHERE ZIP=##ZIP_CODE## 143     </SQL> 144  WEATHER= 145     <HTTPGET>http://webservices. 146      weather.com/weather?zip=##ZIP_CODE## 147     </HTTPGET> 148</DYNAMIC_TOKENS> 149 <!-- Final Recipients and Attributes--------------- --150    Note that the format is a specific format with151      the first row being the column names and the 152    columnseparator being “::”. These parameters 153    can also be specified inthe Mailing--> 154 <FINAL_RECIPIENTS> // this can be defined in XML also155   email_address::favorite_color::zip_code 156  frank@strongmailsystems.com::blue::94131 157  shirish@strongmailsystems.com::red::90065 158  tim@strongmailsystems.com::purple::60611 159 </FINAL_RECIPIENTS> 160<HEADERS> 161   <!-- These headers would override the 162   headers fromthe original e-mail if they 163   exist. If they do not exist, then the164   originating e-mail headers will be 165   forwarded --> 166   From: StrongMail Customer Support 167 </HEADERS> 168 <BODY> 169   Date: September 12, 2005 170   Dear ##CRM_FIRST_NAME##: 171   Your account IDis ##CRM_ACCOUNT_ID## 172   Your favorite color is ##favorite_color##173   ##TRACK##http://www.strongmailsystems.com 174   ##OPENTAG## 175<!-- Further personalization rules that the EXML 176 server can execute--> 177   <IF favorite_color == blue> 178     <IMG SRC=“blue.gif”> 179  </ELSE> 180     <IMG SRC=“transparent.gif”> 181   </IF> 182   Here isa list of the branches near you: 183   ##BANK_BRANCHES## 184   Here isyour local weather: 185   ##WEATHER## 186   ##CANSPAN## 187   <!--global token that exists on MTA --> 188   <!-- These are the CAN-SPAMlegal compliance 189   footers in the email provided by tokens --> 190</BODY> 191 </EXML>

The exemplary electronic request above includes specific XML tags andother statements that are used to construct an MTA production mailing.One tag is the EXML tag (line 100) that is used to indicate that theelectronic request is in fact an electronic request of the form of thepresent invention as opposed to some other type of message. The contentof the electronic request is contained within EXML start and closingtags. In the example above, the EXML tag is on line 100 and the closingtag is on line 191. Within the EXML opening and closing tags are found avariety of other tags and data elements. One data element is an optionaltype flag (line 101) that serves as a debugger code. When the optionaldebugger code is activated, no message is sent by mail transfer agentmodule 246.

Another tag is a STATIC_TOKENS tag. The STATIC_TOKENS opening (line 108)and closing (line 134) demark a portion of the EXML message that definesstatic tokens. Static tokens are elements of information that, oncedefined, do not change. Three possible types of static tokens areliteral, CRM, and predefined eMTA tokens.

Another type of tag that can be found in the exemplary electronicrequest is the DYNAMIC_TOKENS tag. The DYNAMIC_TOKENS opening (line 136)and closing tag (line 148) demark tokens that are filled by callbacks toan external database such as, for example, customer data repository 44or other type of database 56 on computer 10 of FIG. 3. In fact, dynamictokens can be filled by callbacks to specific web site addresses and/orweb services. Dynamic tokens are executed by eMTA 246 at runtime inorder to retrieve requested information.

Yet another type of tag that can be found in the exemplary electronicrequest is the FINAL_RECIPIENTS or FINAL_RECIPIENT tag. TheFINAL_RECIPIENTS opening (line 154) and closing tag (line 159) specifiesthe recipients of the final digital message (e.g., e-mail message) thatis encoded in the electronic request. There can be a single recipient ora plurality of recipients.

A portion of the electronic request, denoted by HEADER tabs, specifiesthe format of the header of the encoded message that is sent to one ormore recipients 206 by mail transfer agent module 246. Still anothertype tag that can be found in the exemplary electronic request is a BODYtag. In the exemplary electronic request above, the BODY opening tag(line 168) and closing tag (line 190) demark a portion of the electronicrequest that specifies the format of the body of the encoded messagethat is sent to one or more recipients 206 by mail transfer agent module246.

The present invention places no restrictions on the order that each ofthe aforementioned tags appear within the electronic request. However,generally speaking, the EXML tag is the first tag and all other tags arenested within the EXML start and end tags in embodiments that make useof such tags. In other embodiments, other forms of tags and/or logic isused. There is no requirement that data belonging to each of theaforementioned tags appear in the EXML message. For example, in someembodiments, all or a portion of the data belonging to one of theaforementioned tags is located in one or more files or databases thatare external to the electronic request. Such external files or databasescan, for example, be at one or more locations that are addressable bymessage personalization module 244 via network/Internet 34. Forinstance, in some embodiments, the electronic request can refer messagepersonalization module 244 to a specific URL address in order to obtainall or a portion of the data belonging to any of the aforementionedinformation elements.

Now that an overview of the architecture of exemplary electronicrequests has been given, more details of each of the tags in an EXMLmessage, which is one form of electronic request, will be provided withreference to specific lines of code in the example above.

Line 100. The EXML message is typically contained within the EXMLbeginning (<EXML>) and ending (</EXML>) tags. The presence of such tagsin an e-mail originating from client 10 and that is parsed by module 244notifies the module that the electronic request is an electronic requestof the present invention as opposed to a conventional set of MTAinstructions or other form of conventional communication such as a voicemail. In the example provided above, the tag that triggers messagepersonalization module 244 is “<EXML>.” However, the present inventionis not limited to such a tag name. In other embodiments of the presentinvention, other tag names can be used to trigger personalization module244 to recognize electronic requests of the present invention. All thatis required is that the tag present in the electronic request be the onethat module 244 is programmed to recognize. Furthermore, module 244 canbe programmed to recognize multiple different tags, where each of thedifferent tags signifies an associated set of rules. For example<TAG1>can signify an electronic request having one type of commandstructure and statements (information elements) whereas <TAG2> cansignify an electronic request having a different command structure andstatements (information elements). It will be appreciated that theinvention is by no means limited to the tags set forth in this example.Users are free to create their own specialized DTD's (Document TypeDefinition) for EXML so that they can specify tags for custom logic.

Lines 101-107. In some embodiments of the present invention, theelectronic request optionally has the feature of providing a test mode.In such a test mode, the electronic request is parsed by module 244 butno encoded messages are actually sent out by mail transfer agent module246. Any errors that are found in the test run are reported back toclient 10 so that the electronic request can be debugged. In someembodiments, such errors will be sent back to the sender within anotherRETURN TO e-mail with the errors and an indication of the actual linenumbers within the electronic request that caused the errors. The testmode is advantageous because it allows for the MTA production mailing tobe fully debugged before e-mail or other forms of digital messages aresent to intended recipients 206. In this way, intended recipients arenot bothered with e-mail or other forms of digital messages that haveincorrect information. One form of bug that can arise is incorrectaccess privileges to customer data repository 44 or other databases 56.For example, if the electronic request does not have the correctpassword encoded in the message, access to personalized informationabout each of the intended recipients will not be obtained and theencoded e-mails or other forms of encoded messages to one or moreintended recipients will not be customized In some embodiments, encodedmessages are not customized at all for specific recipients. Rather, suchmessages include logically encoded data (e.g. weather, maps) and/or areintended for special purpose computers (e.g., blog sites).

Lines 108-135. Lines 108 through 135 of the exemplary electronic requestenumerate specific types of static tokens. Three different types ofstatic tokens are defined within the STATIC_TOKENS tag literal (lines110-112), CRM tokens (lines 113-117), and predefined eMTA tokens(118-133). Literal tokens are for use only in a given electronicrequest.

For instance, line 111 of the exemplary electronic request provides astatic token that defines the literal “zip_code” having the value“94555.” Further, line 112 of the electronic request provides a statictoken that defines the literal “mailingid” having the value “1234.”

Lines 113 through 117 of the electronic request demark static tokensthat are CRM tokens. CRM tokens can be used in embodiments where theelectronic request is routed through a CRM, such as CRM 70 of FIG. 1prior to routing the electronic request to module 244. When theelectronic request passes through CRM module 70, the CRM tokens arepopulated with appropriate information. In the case of the exemplaryEXML message above, the static CRM tokens “CRM_EMAIL,” CRM_FIRST_NAME,”“CRM_LAST_NAME,” as well as “CRM_ACCOUNT_ID” are used to denote selectpersonalized information about recipients 206. These tokens arepopulated with information by a customer management relationshipsoftware product such as Siebel 7.8 (Siebel Systems Inc., San Mateo,Calif.).

Lines 118 through 133 describe static tokens that are already defined bymail transfer agent module 246. One such type of token is theVIRTUAL_SERVER token that specifies a virtual route. Each such virtualroute can have different characteristics to handle different classes ofdigital messages. The “##CANSPAM##” is placed in an electronic requestwhen the encoded messages of the electronic request must comply with theCAN-SPAM law. The CAN-SPAM Act of 2003, Controlling the Assault ofNon-Solicited Pornography and Marketing Act, establishes requirementsfor those who send commercial email, spells out penalties for spammersand companies whose products are advertised in spam if they violate thelaw, and gives consumers the right to ask e-mailers to stop spammingthem. The law, which became effective Jan. 1, 2004, covers e-mail whoseprimary purpose is advertising or promoting a commercial product orservice, including content on a Web site. If this is the primary purposeof the digital messages encoded by a given electronic request, than the##CANSPAM## static token is added to an electronic request. The eMTAthen ensures that the encoded messages of the electronic request complywith the CAN-SPAM act. For instance, the CAN-SPAM Act bans false ormisleading header information. Furthermore, the e-mail's “From,” “To,”and routing information, including the originating domain name ande-mail address, must be accurate and identify the person who initiatedthe e-mail. Furthermore, the CAN-SPAM Act prohibits deceptive subjectlines. The CAN-SPAM Act further requires that email give recipients anopt-out method, e.g., provide a return email address or anotherInternet-based response mechanism that allows a recipient to ask thatfuture email messages to that email address cease. As such, the##CANSPAM## static token is used to invoke CAN-SPAM act compliance.

Another type of static token that can be interpreted by mail transferagent module 246 are ##HABEAS_HEADERS## tokens. Habeas Inc. (MountainView, Calif.) provides a license to add hidden information to youre-mail messages that certifies to certain recipients that the emailaddress to which it is being sent was acquired using a fully confirmedlegal opt-in method (e.g., double opt-in). Placement of the static token##HABEAS_HEADERS## in an EXML message instructs module 246 to use aHabeas header.

Still another type of static token that can be interpreted by module 246are static tokens such as ##TRACK## or ##OPENTAG##. When module 246identifies such tokens, it inserts logic into the outgoing e-mails sentto recipients 206 designed to track user events such as when such e-mailis opened, or when portions of such e-mail (e.g. embedded URLs in thee-mail) are clicked by a user. Other events that can be tracked by suchlogic include subscribe and unsubscribe events. For example, one form ofstatic token that can be interpreted by module 246 causes module 246 toadd an unsubscribe option to outgoing e-mail. When a recipient selectsthe unsubscribe option, this information is communicated back to system10 and the recipient is removed from a mailing list.

Still another type of static token are XML/XSL rules that can be encodedin standard extensible stylesheet language (XSL). XSL is a family ofrecommendations for defining XML document transformation andpresentation. XSL includes (i) XSL transformations (XSLT) which is alanguage for transforming XML, (ii) the XML Path Language (XPath) whichis an expression language used by XSLT to access or refer to parts of anXML document (XPath is also used by the XML Linking specification), and(iii) XSL formatting objects (XSL-FO) which is an XML vocabulary forspecifying formatting semantics. An XSLT stylesheet specifies thepresentation of a class of XML documents by describing how an instanceof the class is transformed into an XML document that uses a formattingvocabulary, such as (X)HTML or XSL-FO. Such XSL tokens can be used toprovide personalization rules, for example, for reporting based onmailing-id, etc.

Lines 135-148. Lines 135 through 148 of the exemplary electronic requestdemark the start and end of the DYNAMIC_TOKENS tag. Nested within theboundaries of the DYNAMIC_TOKENS tag are definitions of specific typesof information and/or instructions for obtaining such information. Thisinformation is used to form customized encoded messages. For instance,lines 137-143 of the electronic request define an SQL query instruction.The SQL query instruction is designed to connect to the database host“db-host1”, to login to the database as user “smail” with a password of“1234” and to select all branch names records from the tablebranch_table having a zip code that matches ##ZIP CODE##. Recall that##ZIP CODE## is a static token that is defined on line 111 of the EXMLmessage. The value for ##ZIP_CODE##, 94555 is passed to the SQL query bymessage personalization module 244 and/or mail transfer agent model 246when the SQL query is executed.

Another example of a DYNAMIC_TOKEN is found on lines 144-147 of theelectronic request, which defines an HTTP request. The HTTP request isdesigned to obtain the weather at the geographical region defined by##ZIP_CODE## from the USR http://webservices.weather.com.

Lines 149-159. Lines 149 through 159 of the exemplary electronic requestdemark the start and end of a FINAL_RECIPIENTS tag. Nested within theboundaries of the FINAL_RECIPIENTS tag are the e-mail addresses ofrecipients 206. Specifically, line 155 defines the data structure of thee-mail addresses that follow. Line 155 states that each line of data tofollow, up to the end of the FINAL_RECIPIENTS tag on line 159, has threedata elements (i) e-mail address, (ii) the favorite color of theaddressee associated with the e-mail address, and (iii) the zip code ofthe addressee associated with the e-mail address. Line 155 furtherstates that the delimiter between each of these data elements is adouble colon “::”. Thus, line 156 of the exemplary electronic request isparsed to read the e-mail address “frank@strongmailsystems.com,” thefavorite color blue, and the zip code 94131. This zip code is used inthe SQL and HTTP requests defined in the statements nested in theDYNAMIC_TOKENS tag described above.

There is no requirement that the electronic request have more than onefinal recipient. In fact, in some instances there is only one finalrecipient. For example, in the exemplary electronic request above,rather than having the FINAL_RECIPIENT block defined by lines 154through 159, the following block is provided:

200 <!-- Example 2 --> 201 <!-Another example with only 1 FinalRecipient --> 202 <FINAL_RECIPIENT> // this can be defined in XML aswell 203   email_address::first_name::account_id 204##CRM_EMAIL##::##CRM_FIRST_NAME##:: ##CRM_ACCOUNT_ID## 205</FINAL_RECIPIENT>

In this example, line 202 is the opening tag line for a FINAL_RECIPIENTand line 205 is the closing tag line. At line 203, the structure of thedata on line 204 is defined. Specifically, line 203 defines the datastructure of the e-mail address that follows. Line 203 states that line204 has three data elements (i) e-mail address of the addressee, (ii)the first name of the addressee associated with the e-mail address, and(iii) the customer relationship account identifier of the addresses.Line 203 further states that the delimiter between each of these dataelements is a double colon “::”. Thus, line 204 of the exemplary EXMLmessage is parsed to read the e-mail address form three static tokens: aCRM static token entitled “CRM_EMAIL,” a CRM static token entitled“CRM_FIRST_NAME,” and a CRM static token entitled “CRM_ACCOUNT_ID.”Thus, when code lines 200 through 205 are used in the EXML message, theEXML message is passed through CRM 70 in order to fetch the values forthe three CRM tokens.

There is no limit on the types of tokens that can be used in therecipient list. The following example replaces the FINAL_RECIPIENT blockdefined by lines 154 through 159 with the following recipient block inwhich recipients are defined with a mix of CRM static tokens and dynamictokens:

300 <!-- Example 3 --> 301 <!-- RECPIENTS with mix of CRM tokens,Dynamic tokens etc. 302 Note below that BANK_BRANCHES is dynamic anddepends on the 303 actual zipcode for this particular user and isevaluated at 304  runtime for each user --> 305 <FINAL_RECIPIENTS> //this can be defined in XML as well 306email_address::favorite_color::zip_code::bank_branches 307frank@strongmail.com::blue::94131:: ##BANK_BRANCHES## 308shirish@strongmail.com::red::90065::##BANK_BRANCHES## 309</FINAL_RECIPIENTS>In this example, line 305 is the opening tag line for FINAL_RECIPIENTSand line 309 is the closing tag line. Line 306 defines the datastructure of the e-mail addresses that follow. Line 306 states that eachline of data to follow, up to the end of the FINAL_RECIPIENTS tag online 309, has four data elements: (i) e-mail address, (ii) the favoritecolor of the addressee associated with the e-mail address, (iii) the zipcode of the addressee associated with the e-mail address, and (iv) thedynamic token BANK_BRANCHES which uses the zip code of the addresseeassociated with the e-mail address to dynamically find the bank branchesin the vicinity of the user associated with the e-mail address inaccordance with the BANK BRANCHES dynamic token defined by lines137-143. As in the other examples, line 306 further states that thedelimiter between each of these data elements is a double colon “::”.

Lines 160-190. Lines 160 through 190 describe the format of the encodemessage (e.g., encoded e-mail) that is sent to one or more recipients206. The optional HEADER tag at line 160 denotes an optional header thatoverrides the header of the original exemplary electronic request. Anyheader nested within the HEADER start (line 160) and end (line 167) tagis used in the encoded message that is sent by module 246 to one or morerecipients 206. If the HEADER tag is not present in the electronicrequest, then the header of the electronic request is used by module 246as the header of the encoded messages to one or more recipients 206. Inthe exemplary electronic request above, the HEADER statement overridesthe default header so that all encoded messages sent by MTA module 246in response to the electronic request will appear to have originatedfrom “StrongMail Customer Support.”

Lines 168 and 190 of the exemplary electronic request demark the startand end of the BODY tag. Nested within the boundaries of the BODY tag isa description of the body that is sent by module 246 to recipients 206in accordance with the electronic request.

In accordance with line 169 of the exemplary electronic request, thefirst line of such an encode message will say “Date: Sep. 12, 2005.” Inaccordance with line 170 of the exemplary electronic request, the nextline of the encoded message will say “Dear % frame %” where “% frame %”is the first name of a recipient 206 that is obtained from customerrelationship management database 70 in accordance with the static tokenfound at line 115.

Note that a particular “% frame %” is matched up with a particularaddress using, for example, code line 203. In accordance with line 171of the exemplary electronic request, the next line of the encodedmessage says “Your account ID is ##CRM_ACCOUNT_ID##” where “##CRMACCOUNT ID##” is the account identifier associated with the recipient206 (mapped from [% CID %] of the encoded message. The value “[% cid”%]” is obtained from the personalization of the CRM system, then mappedto ##CRM_ACCOUNT_ID## using the static token found at line 117 and ismatched up with a particular address using code such as, for example,line 203 in conjunction with lines 114-117 of the exemplary EXMLmessage.

In accordance with line 172 of the exemplary electronic request, thenext line of the encoded message states “Your favorite color is##favorite_color##” where the phrase ##favorite_color## is the colorassociated with the address to which the encoded message is being sent,as defined within the FINAL_RECIPIENTS tag on lines 154 through 159 ofthe exemplary electronic request. For example, when an encoded messageis being sent to frank@strongmailsystems.com, the E-message will state“Your favorite color is blue.”

In accordance with line 174 of the exemplary electronic request, theencoded message will then have an opening statement. This openingstatement can be one or more form statements that are inserted in allencoded messages sent by MTA module 246. The ##OPENTAG## variable isrecognized by MTA module 246 and/or message personalization module 244and the text associated with this variable is inserted into outgoingencoded messages.

As illustrated in the exemplary electronic request, a wide assortment ofcustomization rules can be executed. Lines 177 through 181 use aconditional if statement to customize the outgoing encode message as afunction of the recipient's favorite color. The recipient's favoritecolor is obtained from the data nested within the FINAL_RECIPIENTS tagof the exemplary electronic request (lines 154-159). If the recipient'sfavorite color is blue, then the outgoing encoded message will containthe image “blue.gif.” Otherwise, the outgoing encoded message willcontain the image “transparent.gif.” Lines 177 through 181 illustratehow the systems and the methods of the present invention allow for theuse of logic expressions in electronic requests in order to constructhighly customized encoded messages.

Next, line 183 of the exemplary electronic request instructs MTA 246 toincorporate in outgoing encoded messages a listing of branches near therecipient 206 of the encoded message. To provide this listing, thedynamic token ##BANK_BRANCHES## is populated by firing the SQL querydefined by lines 137 through 143 with the zip code associated with therecipient of the encoded message as defined in the FINAL_RECIPIENTS tagon lines 154 through 159 of the exemplary electronic request.

Next, line 185 of the exemplary electronic request instructs MTA 246 toincorporate in outgoing encoded messages the weather in the geographiclocation associated with the recipient of the encoded message. Toprovide this information, the HTTP request defined by lines 145-147 ofthe exemplary code is made such that the token ##ZIP_CODE## within theHTTP request is populated with the zip code associated with therecipient of the encoded message as defined in the FINAL_RECIPIENTS tagon lines 154 through 159 of the exemplary electronic request. The token“##WEATHER##” is a dynamic token and line 185 illustrates how such atoken can be used.

Finally, the encoded message is terminated with closing informationdefined by ##CANSPAN##, which is a predefined token provided by MTAmodule 246 on server 202. Here, the CANSPAN token is used to provide afooter that brings the outgoing encoded message in compliance with theCAN-SPAM Act of 2003 or any related legislation including updates to theCAN-SPAM Act.

In some embodiments in accordance with the present invention, a user mayutilize embedded tokens in an electronic request to obtain customizeddata from different resources. In some embodiments a menu choice, suchas those observed for a typical My Yahoo interface, so that the user maychoose to include relevant information by selecting to turn on one ormore of the token features, which are then incorporated into theelectronic request. In other words, in some embodiments of the presentinvention, a graphical user interface that includes menu choices may beemployed by a user in order to construct an electronic request.

In some embodiments in accordance with the present invention, theelectronic request may be sent from one computer to one or more othercomputers. For example, client 10 may be a part of the built-in computersystem associated with a refrigeration unit that sends out electronicrequest in response to certain events, e.g., the quantity of milk supplyin the refrigerator. When the milk supply drops below a predeterminedlevel, client 10 originates and sends out an electronic request. Theelectronic request is sent to, for example, exml@xyz.com, the address ofmodule 244. Module 244 interprets the electronic request and sends anencoded message to the final recipient. Module 244 is hosted by server202. In some embodiments, server 202 hosts a website of a grocery storeand has access to one or more grocery databases. Module 244 parses theelectronic request and extracts relevant information out of the grocerydatabases to generate an encoded message to be posted on the web site ora separate grocery store database (e.g., recipient 206). Productdelivery may be arranged accordingly. Alternatively, module 244 parsesthe electronic request and extracts the relevant information out of thegrocery database to generate an encoded message that gets sent back toclient 10 to compile a grocery list. The encoded message contains, forexample, price and product information for milk products that areavailable at the grocery store. In some embodiments, the encoded messagealso contains additional produce or food or non-food product informationthat is relevant to the product inquiry (e.g., information on cheese oryogurt products may accompany a milk shortage warning message).

In some embodiments in accordance with the present invention, electronicrequests may be sent from a person for use by a recipient that is acomputer itself, as opposed to a person that has access to the computer.Correspondingly, in some embodiments, the originator of an electronicrequest in some embodiments of the present invention is a computer, asin the refrigerator example above, not a person, and, in suchembodiments, the intended recipient is one or people or one or morecomputers. To illustrate one such embodiment, a blog owner may program aclient 10 so that it automatically sends out electronic requests of thepresent invention to the computer system that hosts the blog (e.g.,recipient 206). The electronic request may contain tokens thatcorrespond to, for example, the account ID of the blog owner and topicand general interest information of the blog. In some embodiments, theelectronic request is parsed by module 244 of recipient system 206 togenerate encoded messages that will be posted accordingly on the blogsite. Alternatively, electronic requests may be sent from the computersystem that maintains the blog site to one or more blog owners. Suchelectronic requests contain tokens that correspond to, for example, theaccount ID of the blog owner and topic and general interest informationof the blog. Appropriate information may be retrieved from the Internetand composed into encoded messages to each blog user.

In some embodiments in accordance with the present invention, electronicrequests may be used to retrieve additional information (e.g., gettingcontents for maps, providing driving and weather information). Forexample, a traveler 10 may send an electronic request to a databaseserver 202 to request a road map or driving and weather information ofthe traveling destination. The server parses the request, supplies theappropriate information (e.g., step 316), and returns the information asencoded messages back to the traveler (e.g., step 318). In someembodiments in accordance with the present invention, additional modulesmay be added to the message personalization module (e.g., component 244)such that the returned encoded messages may be converted to voice mails.Exemplary text-voice conversion tools include the voice extensiblemarkup language (VoiceXML). VoiceXML is designed for creating audiodialogs that feature synthesized speech, digitized audio, recognition ofspoken and dual-tone-multi-frequency (DTMF) key input, recording ofspoken input, telephony, and mixed initiative conversations. A goal ofVoiceXML is to bring the advantages of web-based development and contentdelivery to interactive voice response applications.

The exemplary electronic request provided above illustrates theadvantages of the present invention. The XML language used in theexemplary electronic request is used to define a data structure that isdelivered to batch e-mail personalization server 202. The electronicrequests contain all the instructions necessary to obtain encodedmessages including both the data and the body of the message to be sent.Highly customized SQL queries can be encoded in the electronic request.Once constructed, the need to have an IT specialist involved in futurecommunication is obviated. A business development professional simplyrefines the existing XML code of a previous EXML mailing.

Many examples of logic that can be encoded in the electronic requests ofthe present invention have been described. Further examples of logicthat can be included in electronic requests include control structuressuch as selectional structures (e.g., if, conditional assignment,switch) and/or looping constructs (e.g., while, for, break andcontinue). For more description of such logic see The Essentials of C++,Research & Education Association, Piscataway, N.J., 1999, which ishereby incorporated herein by reference in its entirety. Other examplesof logic that can be embedded in the electronic requests of the presentinvention include the seven basic logic gates: AND, OR, XOR, NOT, NAND,NOR, XNOR, and any combination of two or more of these gates.

Still other examples of logic that can be embedded in the electronicrequests of the present invention is symbolic logic such aspropositional calculus. The most basic units in propositional calculusare whole propositions or statements, each of which is either true orfalse. Propositional calculus is used to consider the logicalrelationships that hold among two or three or more such statements.Individual statements are represented by using capital letters of thealphabet as statement constants. Thus, for example, the letters A, B,and C can be used to represent three different statements (e.g., A couldstand for “Alan bears an uncanny resemblance to Jonathan,” B could standfor “Betty enjoys watching John cook,” and C could stand for “Chris andLloyd are an unbeatable team.” Each statement constant designates oneand only one statement. In propositional calculus statement variablesare represented with lower-case letters of the alphabet (beginning with“p”), for example, “Consider any statement, p , . . . ” or “Suppose thatsome pair of statements, p and q , are both true . . . .” Statementvariables can stand for any statements whatsoever, but within the scopeof a specific context, each statement variable always designates thesame statement. Once A is substituted for p, for example, thesubstitution must done consistently; that is, every occurrence of p mustbe taken to refer to A. But if another variable, q, occurs in the samecontext, it can stand for any statement whatsoever—B, or C , or even A.

In the propositional calculus that can be implemented in the electronicmessages of the present invention, the following exemplary statementconnectives or operators can be used:

-   -   ˜ p

    -   • (also symbolized as & or        )

    -   

    -   ⊃ (also symbolized as →)

    -   ≡ (also symbolized as        )

The syntax of using statement connectives to form new, compoundstatements can be stated as a simple rule:

For any statements, p and q,

-   -   ˜p    -   p·q    -   p        q    -   p⊃q    -   p≡q        are all legitimate compound statements.

This rule is recursive in the sense that it can be applied to its ownresults in order to form compounds of compounds of compounds . . . ,etc. As these compound statements become more complex, parentheses andbrackets can be used, just as in the case of algebra, in order to keeptrack of the order of operations. Thus, since A, B, and C are allstatements, so are all of the following compound statements:

-   -   ˜A    -   A·B    -   A        ˜ C    -   C ⊃ (B        A)    -   ˜(˜ B ≡ C)    -   (A        ˜B)=(C ⊃ A)    -   [A        ˜ (C        B)]

The five logical operators are all truth-functional connectives; thetruth or falsity of each compound statement formed by using them iswholly determined by the truth-value of the component statements and themeaning of the connective. Thus, using statement variables in order tocover every possible combination of truth-values (T or F), a convenienttruth-table can be constructed to define the meaning of each statementconnective.

Negation. The “˜” signifies logical negation; it reverses the truthvalue of any statement (simple or compound) in front of which itappears: if the original is true, the ˜ statement is false, and if theoriginal is false, the ˜ statement is true. Thus, its meaning can berepresented by the following truth-table:

p ~p T F F T

Conjunction. The “•” symbolizes logical conjunction; a compoundstatement formed with this connective is true only if both of thecomponent statements between which it occurs are true. Whenever eitherof the conjuncts (or both) is false, the whole conjunction is false.Thus, the truth-table below shows the truth-value of acompound—statement for every possible combination of truth-values forits components:

p q p · q T T T T F F F T F F F F

Disjunction. The symbol “

” signifies inclusive disjunction: a

statement is true whenever either (or both) of its component statementsis true; it is false only when both of them are false as set forth inthe truth table below:

p q p 

 q T T T T F T F T T F F F

Implication. The ⊃ symbol is used to symbolize a relationship calledmaterial implication; a compound statement formed with this connectiveis true unless the component on the left (the antecedent) is true andthe component on the right (the consequent) is false, as shown in thefollowing truth-table:

p q p ⊃ q T T T T F F F T T F F T

Equivalence. Finally, the “≡” is used to symbolize material equivalence,in which the compound statement is true only when its componentstatements have the same truth-value—either both are true or both arefalse as shown in the following truth table:

p q p ≡ q T T T T F F F T F F F T

REFERENCES CITED

The present invention can be implemented as a computer program productthat comprises a computer program mechanism embedded in a computerreadable storage medium. For instance, the computer program productcould contain the program modules shown in FIG. 3 and/or FIG. 4. Theseprogram modules can be stored on a CD-ROM, DVD, magnetic disk storageproduct, or any other computer readable data or program storage product.The program modules can also be embedded in permanent storage, such asROM, one or more programmable chip, or one or more application specificintegrated circuits (ASICs). Such permanent storage can be localized ina server, 802.11 access point, 802.11 wireless bridge/station, repeater,router, mobile phone, or other electronic devices. The software modulesin the computer program product can also be distributed electronically,via the Internet or otherwise, by transmission of a computer data signal(in which the software modules are embedded) either digitally or on acarrier wave.

Many modifications and variations of this invention can be made withoutdeparting from its spirit and scope, as will be apparent to thoseskilled in the art. The specific embodiments described herein areoffered by way of example only, and the invention is to be limited onlyby the terms of the appended claims, along with the full scope ofequivalents to which such claims are entitled.

What is claimed:
 1. A first computer comprising a processor and amemory, the memory comprising instructions, executable by the processor,for: receiving, at the first computer, a human-readable message over anetwork or the Internet from a second computer, wherein thehuman-readable message is in the form of an e-mail; and determining, atthe first computer, whether the human-readable message includes (i) atag originated by a sender of the human-readable message, wherein thetag identifies the human-readable message as a message that is to bepre-processed prior to forwarding the e-mail to a plurality ofrecipients and (ii) human-readable instructions, originated by thesender of the human-readable message, wherein the human-readableinstructions are interpretable by the first computer to direct the firstcomputer to pre-process the human readable message by a pre-processroutine, the pre-process routine including instructions for: requestingand receiving, over a network or the Internet from a third computer,data from one or more data fields of a database responsive to thehuman-readable instructions and without human intervention; andmodifying the human-readable message, thereby creating a plurality ofprocessed human-readable messages; wherein when it is determined thatthe human-readable message includes (i) the tag and (ii) thehuman-readable instructions, pre-processing the human-readable messagein accordance with the human-readable instructions using the pre-processroutine.
 2. The first computer of claim 1, wherein one or more of thehuman-readable instructions in the human-readable message isinterpretable by the first computer to direct the first computer toperform a looping construct, the looping construct being responsive tothe data from the one or more data fields.
 3. The first computer ofclaim 1, wherein one or more of the human-readable instructions in thehuman-readable message is interpretable by the first computer to directthe first computer to (i) send a database query or web services requestover a network or the Internet to the third computer and (ii) receive aresponse to the database query or web services request from the thirdcomputer over a network or the Internet, wherein at least a portion ofthe database query or web services request directs the third computer tomodify its database.
 4. The first computer of claim 1, wherein the datais update information.
 5. The first computer of claim 1, wherein theprotocol of the e-mail is the simple mail transfer protocol (SMTP), theX.400 International Telecommunication Union standard (X.400), the Novellmessage handling service (MHS), or the extended simple mail transferprotocol (ESMTP).
 6. The first computer of claim 1, wherein the databasecomprises a customer relationship management database, an enterpriseresource planning database, a human resource database, or a supply chaindatabase.
 7. A physical medium maintaining human-readable instructionsinterpretable by a first computer to direct the first computer: toreceive at the first computer a human-readable message over a network orthe Internet from a second computer, wherein the human-readable messageis in the form of an e-mail; to determine, at the first computer,whether the human-readable message includes (i) a tag originated by asender of the human-readable message, wherein the tag identifies thehuman-readable message as a message that is to be pre-processed prior toforwarding by the e-mail to a plurality of recipients and (ii)human-readable instructions, originated by the sender of thehuman-readable message, wherein the human-readable instructions areinterpretable by the first computer to direct the first computer topre-process the human readable message by a pre-process routine, thepre-process routine including instructions for: requesting andreceiving, over a network or the Internet from a third computer, datafrom one or more data fields of a database responsive to thehuman-readable instructions and without human intervention; andmodifying the human-readable message, thereby creating a plurality ofprocessed human-readable messages; and when it is determined that thehuman-readable message includes (i) the tag and (ii) the human-readableinstructions, pre-processing the human-readable message in accordancewith the human-readable instructions using the pre-process routine.
 8. Aphysical medium as in claim 7, wherein one or more of the human-readableinstructions in the human-readable message is interpretable by the firstcomputer to direct the first computer to perform a looping construct,the looping construct being responsive to the data from the one or moredata fields.
 9. A physical medium as in claim 7, wherein one or more ofthe human-readable instructions in the human-readable message isinterpretable by the first computer to direct the first computer to (i)send a database query or web services request to said third computer andto receive a response to the database query or web services request fromsaid third computer, wherein at least a portion of the database query orweb services request directs the third computer to modify its database.10. A physical medium as in claim 7, wherein the data is updateinformation.
 11. A physical medium as in claim 7, wherein the protocolof the e-mail is the simple mail transfer protocol (SMTP), the X.400International Telecommunication Union standard (X.400), the Novellmessage handling service (MHS), or the extended simple mail transferprotocol (ESMTP).
 12. A physical medium as in claim 7, wherein thedatabase comprises a customer relationship management database, anenterprise resource planning database, a human resource database, or asupply chain database.
 13. A computer program product for use inconjunction with a first computer, the computer program productcomprising a computer readable storage medium and a computer programmechanism embedded therein, the computer program mechanism comprisinginstructions for: receiving, at the first computer, a human-readablemessage over a network or the Internet from a second computer, whereinthe human-readable message is in the form of an e-mail; determining, atthe first computer, whether the human-readable message includes (i) atag originated by a sender of the human-readable message, wherein thetag identifies the human-readable message as a message that is to bepre-processed prior to forwarding the e-mail to a plurality ofrecipients and (ii) human-readable instructions, originated by thesender of the human-readable message, wherein the human-readableinstructions are interpretable by the first computer to direct the firstcomputer to pre-process the human readable message by a pre-processroutine, the pre-process routine including instructions for: requestingand receiving, over a network or the Internet from a third computer,data from one or more data fields of a database responsive to thehuman-readable instructions and without human intervention; andmodifying the human-readable message, thereby creating a plurality ofprocessed human-readable messages; wherein when it is determined thatthe human-readable message includes (i) the tag and (ii) thehuman-readable instructions, pre-processing the human-readable messagein accordance with the human-readable instructions using the pre-processroutine.
 14. The computer program product of claim 13, wherein one ormore of the human-readable instructions in the human-readable message isinterpretable by the first computer to direct the first computer toperform a looping construct, the looping construct being responsive tothe data from the one or more data fields.
 15. The computer programproduct of claim 13, wherein one or more of the human-readableinstructions in the human-readable message are interpretable by thefirst computer to direct the first computer to (i) send a database queryor web services request over a network or the Internet to the thirdcomputer and (ii) receive a response to the database query or webservices request from the third computer over a network or the Internet,wherein at least a portion of the database query or web services requestdirects the third computer to modify its database.
 16. The computerprogram product of claim 13, wherein the data is update information. 17.The computer program product of claim 3, wherein the protocol of thee-mail is the simple mail transfer protocol (SMTP), the X.400International Telecommunication Union standard (X.400), the Novellmessage handling service (MHS), or the extended simple mail transferprotocol (ESMTP).
 18. The computer program product of claim 13, whereinthe database comprises a customer relationship management database, anenterprise resource planning database, a human resource database, or asupply chain database.
 19. The computer program product of claim 13,wherein the data comprises customer data.
 20. The computer programproduct of claim 13, wherein the requesting includes an HTTP request.